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"A Telecommunications System Controller Framework" 

I ntroduction 

5 The invention relates to a telecommunications system controller framework. 

Heretofore, the approach for telecommunications system controllers has been to link 
die software very closely with the hardware resources and provide much dedicated 
functionality. This approach can provide a fast response time for real time 
10 telecommunications control, however, it lacks flexibility and modifications are 
difficult to make. 

Therefore, one object of the invention is to provide a framework which operates 
efficiendy in real time, and which may be easily modified to cater for changing 
1 5 telecommunications resources and volume requirements. 

Statements of Invention 

According to the. Invention, there is provided a telecommunications system controller 
20 framework comprising:- 

application domain base objects in a base level; and 

meta data for the base objects in a meta level. 



25 



Preferably, the meta data comprises meta objects, and there is preferably one meta 
object associated with each base object class. For example, there may be a base 
object associated with each slot in a telecommunications exchange rack, and one 
meta object associated with the slot class. 
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Preferably, the meta level operates in reaction to the base objects. Thus, the base 
objects perform the application processing and either make requests to the meta 
objects or transfer certain information to the meta objects so that they can react. 

5 In one embodiment the meta data includes base object containment information. 
Preferably, the meta data comprises means for using the containment information for 
interrogating the base object containment hierarchy to locate a required object in 
response to a request from a requesting base object. By storing the containment 
information, the meta level can interrogate the base level to locate required objects. 

10 

In one embodiment, the meta data includes persistence data. This allows the base 
objects to be free from the need to perform any data persistence operations, thus 

v. 

helping to provide a fast response time, and also consistency in the manner in which 
persistence data is dealt with. 

15 

In one embodiment, the meta objects comprise means for performing persistence 
data operations transparentiy to the base objects. 

In another embodiment, the meta data includes real resource information for 
20 attributes of the base objects. Preferably, the meta objects comprise means for 
verifying base object proposals to update real resource attributes, and for performing 
the updates if approved. In one embodiment, the meta data objects comprise means 
for publishing real resource update events on a channel. The base objects are 
divorced from the real resources, thus allowing flexibility as the base objects may be 
25 modified to cater for different functionality without the need to deal with the manner 
in which they interface with the real resources. Location on a channel is an effective 
way of disseminating real resource update information. 

In one embodiment, the meta data includes condition and alarm information. 

30 
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Preferably, the meta objects include controller backup information and means for 
updating a backup controller. 

Detailed Description of the Invention 

5 

The invention will be more clearly understood from the following description of 
some embodiments thereof, given by way of example only with reference to the 
accompanying drawings in which :- 

10 Fig. 1 is a diagrammatic representation of a framework; and 

Figs. 2 to 15 inclusive a diagrams indicating interaction of layers in the 
framework. 

15 Referring now to Fig. 1, a framework 1 for telecommunications system controller is 
illustrated. In this embodiment, the telecommunications system is for handling 
ATM cells. The framework 1 comprises an application domain base level 2 having 
base objects 3. It also comprises a meta level 4 comprising meta objects 5. In the 
example illustrated, the base objects 3 are for telecommunications system card slots. 

20 This is a class of base object and there is one meta object 5 for each class. 

Briefly, the base objects 3 transmit various requests and signal actions to the relevant 
meta object 5.. The meta object 5 accesses the database 6 and carries out various 
actions relating to base object containment, persistence data, real resource update, 
25 and controller backup updating. The meta level 4 interfaces with real resources 10. 

Referring now to Fig. 2, a general scenario illustrating operation of the framework 1 
is illustrated. In this illustration, a slot object 3 accesses a corresponding meta object 
5, which in turn accesses a resource attribute adapter 11. In general, the base level 
30 defines the application logic, while the meta level performs various actions which 
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can be more efficiently performed by the meta objects. The meta level describes a 
number of different aspects of the base level software including containment 
information, information on which attributes are persistently stored, real resource 
information, and backup information. 

5 

Thus, complex processes such as downloading all of the information in an object 
hardware can be performed by the meta level 4. 

Referring to Fig. 3, an example is illustrated whereby an attribute is set using a base 
10 level function. Application code calls a setLineCoding method on a SlotDo base 
object 3. This informs the meta level, calling the setFourBaseLevel function on the 
meta attribute. The meta attribute verifies the new value can indeed be changed 
from its point of view. If for example the attribute was representing a value on the 
line card, the real resource aspect of the meta object would have provided a 
15 verification strategy object to the meta attribute. In this case the verification strategy 
object would try setting the attribute on the line card. 

Referring now to Fig. 4, an example is illustrated whereby a parent object creates a 
contained object. When doing this, it informs the meta level of the new object using 
20 notifyCreate. There are three phases as follows :- 

(a) construction, in which the object is allocated, 

(b) initialisation, in which it is fully set up, and 

25 

(c) notification, in which the meta object is notified. 
These three phases are controlled by the parent object. 



As stated above, there is one meta object per class of domain objects. Meta objects 
are containers for other objects which describe the domain object class and contain 
attributes, actions, an other information such as containment and persistence 
information. The meta objects also contain event channels which are informed when 
various events take place. For example, subscribers can learn of instance creation 
and deletion using these channels. In the example of Fig. 3, a persistence aspect acts 
as a subscriber receiving notifications of instance creations. 

In more detail, the base objects represent the problem domain and include card, slot 
and ATM interface objects. They are implemented as standard C++ objects and 
have get/set methods for attributes. The method may use methods on other base 
objects and they may create their contained objects and may contain state, state 
machines and support alarm conditions. The base object invoke services on the meta 
level. In an example described above, where an attribute is being set on the base 
level the base level invokes a method on the meta level informing it of attribute value 
changes. 

The attributes are contained in the meta objects 5. Attributes can be get/set from the 
meta level as well as from the base level. This is used when attribute values are 
coming from the meta level as well as from the base level, such as from persistent 
storage. Referring to Fig. 5, a mechanism for getting and setting attributes is 
described. The attribute calls the base level functions for setting and getting the 
value. 

Meta attributes are declared using a hierarchy of abstract classes to avoid including 
much code in header files. Referring to Fig. 6, a mechanism for getting an attribute 
from the meta level is illustrated. 



Meta actions support the domain concept of actions in the domain object. They are 
informed when the base level is running an "action". They can also run the action 
from the meta level. 

Keys are simple classes which represent the information needed to uniquely identify 
and instance of a class. Keys are made of inheritance chains. If an object of the class 
can be contained in objects of another class then the set of that class will inherit from 
its container's key class. In this example, Slot is contained in Shelf. Keys can be 
used to find an instance of a base object. This behaviour is supported from the meta 
level containment information, as illustrated in Fig. 7. The opposite scenario can 
also happen, namely an instance can set a key value. To do this the instance sets the 
part of the key it understands. It needs its parent object to set the rest of the key and 
so on up the tree. 

The containment information of the meta level provides the following functionality: 

finding a domain object using a stream representation of its identity. 

creating a new domain object identified by a string representation of its 
identity. 

creating an iterator for instances of the domain class. 

finding an object based on a key representation of its identity. 

The "contain info" needs to know information such as the string representation of 
the class name, and this is obtained from the meta object. It also needs the 
containment information from its container classes to perform some of its 
functionality. Accordingly, instances of containment information objects tend to be 
changed together in a way that reflects the containment tree. 



There are a number of different concrete containment information classes which 
implement the generic behaviour specified by the abstract ContainlnfoFor. These 
are: 

SingleParentcontainlnfoFor - a contain info for a class of objects which is 
directly contained by a singleton. The objects are not unique within their 
container and so need an identifier to specify them uniquely within a 
container. 

- UniqueContainlnfoFor - a contain info for a class of objects which are 
unique within their container (e.g. there can be only one Card in a Slot). 

- ChildContainlnfoFor - stores containment meta-level information for 
objects which can be contained in other objects. The objects are not 
unique within their container and so need an identifier to specify them 
uniquely within a container. 

Referring to Fig. 9, an example problem domain is illustrated in which there is a 
singleton representing the whole system, shelves are contained in the system, slots 
and fans are contained in a shelf and cards are uniquely contained in a slot. 

Referring to Fig. 10, ChainedContainlnfo classes for the above problem domain 
containment tree are illustrated. The ShelfMeta contains the 

SingleParentContainlnfoFor. It also contains ContainlnfoAdapers for its two types 
of contained objects. 

The meta level classes for containment need to use facilities implemented by base 
level. These facilities are defined in the following two abstract classes:- 



ContainerOf - specifies the class is a container of another type of object. 
Means findObject, findFirstObject and findNextObject, all taking an 
identifier, must be implemented. 

ContainerOfUnique - specifies the class is a container of a unique object. 
Means findObject taking no identifier must be implemented. 

Referring to Fig. 11, the class declarations for the domain objects shelf and slot are 
illustrated. 

Some of the attributes of the base objects need to be persistently stored and this is 
handled by a meta object. The meta object contains an "AbstractPersistObject" 
adapter in the same way. The AbstractPersistObject provides interfaces whereby it 
can load all objects of a class from persistence and can subscribe to object creations 
and deletions. It also contains AbstractPersistAttr objects which are created for each 
attribute which is persistent. 

There are two different concrete types of AbstractPersistObject. The 
PersistStaticObjectAdapterFor is for domain objects which are expected to exist 
before the loadObjectsFromPsl function is called. There are a fixed number of them 
in the system and they merely need to be initialised. 

The loadObjectFromPsl goes through each entry in the persistence storage layer, 
finds the existing object that refers to the entry, then uses the AbstractPersistAttr 
objects to extract the information from the raw persistence storage and set the 
appropriate attributes. 

The other concrete AbstractPersistObject is the PersistDymanicObjectAdapterFor. 
This concrete class is used where the instances are not expected to pre-exist before 
the loadObjectsFromPsl cal and the persist adapter is going to need to cause them to 
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be created. The container of the object is going to do the actual creating and as such 
will need to implement the makeObject function. 

Referring to Fig. 12, the declarations for setting an attribute are illustrated. The 
5 AbstractPersistAttr subscribes to changes in the meta attribute and persistendy stores 
the new values when changes do happen. The mechanism for loading an object from 
persistence storage is illustrated in Fig. 13. 

In the example illustrated, the contain info is passed the whole stream. It finds the 
10 container and calls makeObject on. If the whole operation was successful^ a new 
object is returned. This is then initialised using the storage from the persistence 
layer, finally the notifyCreate is called on the meta level. 

Three phases of construction used form the persistence layer are shown in Fig. 14. 
15 the PersistDymanicObjectAdapterFor uses the makeObject to create the object. It 
uses setObjectFromStorage to initialise it. It then informs the meta level using the 
notifyCreate. 

The meta level is also used for keeping track of and updating real resources. 
20 Typically, there are proxy objects for interacting with objects on the real resource. 
There are two scenarios :- 

(a) When the attribute is set the real resource must try to set the value first. 
This results in talking to a middleware proxy. If this works, the rest of the 

25 process of setting an attribute is run. 

(b) If the real resource needs to be configured from the controller, in this case 
all of the real resource attributes need to be downloaded to the hardware. 
An action means calling a proxy function on the real resource, the proxy 

30 function can be called and return-checked in the base object function. If 
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an attribute is read-only on the hardware and it can change autonomously, 
the get function in the domain object can call the proxy directly to get the 
value from the hardware. 

A mechanism for setting an attribute on a real resource is illustrated in Fig. 15. 

The meta level also provides an agent interface to the base objects for the agent sub- 
system. Some attributes may not be visible on the agent interface or they may be 
more restricted in their scope i.e. read-only instead of read/write. 

Two other aspect of base objects and their representation as meta objects are 
polymorphism and text interfaces. Polymorphism is where there is a base class 
domain object from which derived classed are to be inherited, the derived classes 
want to add new attributes and actions and so will have extra meta information as 
well as the information from the base class. 

The text interface provides facilities for representing objects and attributes as text 
strings, it is used by the CLI software. 

The meta-level architecture may also support domain object versioning. 

It will appreciated that the invention allows application code and logic to be 
independent of application level services. This means that changes to horizontal 
application services can be made without affecting the general application logic, 
avoiding sweeping changes to the software system. These advantages have been 
achieved with a very simple and well defined interfaces between the base and the 
meta level. 
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New functionality can be added to the system without affecting the application code 
because must of the persistence, real resource interface, text interface, and auditing 
functionality can be written in terms of the meta level. 

The invention also achieves a high level of reuse and qualification of the system is 
simplified. 

The invention is not limited to the embodiments described, but may varied in 
construction and detail. 
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Claims 

1. A telecommunications system controller framework comprising:- 

application domain base objects in a base level; and 
meta data for the base objects in a meta level. 

2. A framework as claimed in claim 1, wherein the meta data comprises meta 
objects. 

3. A framework as claimed in claims 1 or 2, wherein there is one meta object 
associated with each base object class. 

4. A framework as claimed in any of claims 1 to 3, wherein the meta level 
operates in reaction to the base objects. 

5. A framework as claimed in any preceding claim, wherein the meta data 
includes base object containment information. 

6. A framework as claimed in claim 5, wherein the meta data comprises means 
for using the containment information for interrogating the base object 
containment hierarchy to locate a required object in response to a request 
from a requesting base object. 

7. A framework as claimed in any preceding claim, wherein the meta data 
includes persistence data. 

8. A framework as claimed in claim 7, wherein the meta objects comprise means 
for performing persistence data operations transparently to the base objects. 
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A framework as claimed in any preceding claim, wherein the meta data 
includes real resource information for attributes of the base objects. 

A framework as claimed in claim 9, wherein the meta objects comprise means 
for verifying base object proposals to update real resource attributes, and for 
performing the updates if approved. 

A framework as claimed in claim 10, wherein the meta data objects comprise 
means for publishing real resource update events on a channel. 

A framework as claimed in any preceding claim, wherein the meta data 
includes condition and alarm information. 

A framework as claimed in any preceding claim, wherein the meta objects 
include controller backup information and means for updating a backup 
controller. 
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